Build Numbers
Patrick Robertson
Rob McBroom
Patrick Robertson
Henning Jungkurth
and commit-SHAs? What's the point in introducing another number? A
number that basically says...nothing. You still have to figure out the
pull request and/or commit where something went wrong.
Currently, the build number has exactly one purpose: To be used in the
update system to communicate that there's a new version available.
That's fine. We don't need to add another purpose to it. Especially
when we already have enough ways to talk point where changes occurred.
I don't get it.
But...if you guys insist on doing this, it should be done
automatically. This shouldn't be left for a human, who will, most
likely, forget it at some point. :-p
I think it can be done using a post-merge git hook.
Patrick Robertson
Henning Jungkurth
> build number to internally track where things are.
Because everybody does it, it must be right. You know the old "if
everybody jumped off a cliff, ..." argument? ;-)
But I'm not saying the concept must be wrong. I'm just trying to
figure out how this would actually help us.
> OK so you don't have to use it to find bugs, but I've finally started using
> a 'testing branch' where I've merged lots of different pull requests. I
> personally want to know when I'm running this, or running the released ß65.
>
> E.g. If I get a crash, forget about it, then look at the crash log. It'll
> say "version: 3925" and I'll remember - oh yeah, that's when I merged in
> this and this.
But...you wont. With the system you proposed, the build number will b
only be increased after something has been merged into master. All the
things in your testing branch wont be merged yet, or you wouldn't be
testing them.
And even if it did. What happens if you have several testing
branches? Each has (somehow) a different number. Would you really
remember which number would correspond to which merged pull requests?
I most likely wouldn't.
Maybe it would make sense to include the branch name in the build
number. Can the build number be a build name? If not, include the
branch name in the version. Of course only for debug-builds. That
would make sense to me. Then you could name your testing branches
nicely and actually remember what you merged in there.
But that would still be no reason to increase the build number after
each merge into master.
Now, if we would have nightly testing releases...or, to be more
correct, testing releases after each merge, increasing the build
number each time would make sense. But we don't.
So I still don't see the point. Feel free to enlighten me. ;-)
> If the number basically says nothing, then why do we have it there at all?
> It is a build number after all - this is the whole reason behind its
> existence!
It does say something. It says "This is a new released version. So,
dear QS-apps out therem if you check for updates, download this." I
think that's enough of a reason for its existence.
Rob McBroom
> Currently, the build number has exactly one purpose: To be used in the update system to communicate that there's a new version available. That's fine. We don't need to add another purpose to it.
The way I understood it, we aren’t adding another purpose to it. We’re just defining a concrete process to increment the number, instead of “Eh, I guess I’ll increase it by 3 or so”. It’s true that there’s a lot of room for human error, so we can talk about how to address that.
I don’t know enough about Git to say, but does this number always increase?
git rev-parse --short HEAD
If so, could we use that as our build number? Would the update system handle large hex numbers OK? If so, we could probably have a hook to set that for us. (It could also be converted to decimal if needed.)
On Feb 23, 2012, at 4:11 AM, Patrick Robertson wrote:
> but I've finally started using a 'testing branch' where I've merged lots of different pull requests. I personally want to know when I'm running this, or running the released ß65.
I can usually tell because fewer things are broken. (And because I never run the released version other than to test/compare things.)
Incrementing the number is still a manual process, so on a private testing branch, you could just set it to whatever you want. No need to convince anyone of anything. :-)
Rob McBroom
> I don’t know enough about Git to say, but does this number always increase?
Answer: No. It’s all over the place.
As you can imagine though, we are not the first people to think about this. Haven’t had time to read through all the suggestions, but I’m sure we can find an answer here…
http://stackoverflow.com/questions/677436/how-to-get-the-git-commit-count
Rob McBroom
> On Feb 23, 2012, at 9:20 AM, Rob McBroom wrote:
>
>> I don’t know enough about Git to say, but does this number always increase?
>
> Answer: No. It’s all over the place.
On the other hand, does that matter? On qsapp.com, there’s only ever one version advertised for each update type, right? So when the application is deciding whether or not there’s a new version, should it care if the number is higher or lower? Couldn’t it just check to see if the number is *different*? It’s not as though typical users will be running a version that’s newer then what’s on qsapp.com.
This might even be a benefit. If there were some serious bug emergency, we could put a previous release out there and users would be notified to download it automatically. As long as it’s not a bug in the update system itself. ;-)
The only drawback that comes to mind it that it will constantly alert us devs because our build number will never match, but I can live with that.
Thoughts?
Henning Jungkurth
just...changes? No way. That's not good.
1. It's confusing. To me. To the users. "I just updated to a new
version, but now my build number than before. Was that a downgrade
instead?"
2. How do you make sure you don't get the same number twice?
Please just make it increase by one on each merge.
What was wrong with just using the build number as it is now and
automatically increasing it by one using a post-merge git hook script?
Btw. in case I wasn't really clear before: I'm not opposed to this. I
just don't see the point. And I'm trying to make sure we don't forget
anything.
One more btw.: What happens during pre-release? When we find a bug in
the pre-released version, push a bug-fix, increase the build number
and do another pre-release. At the same time, we keep developing and
merge stuff into master, increasing the build number as well. Now, we
suddenly have the same build number twice. It's not a big problem, but
we need to be aware of it.
And another btw.: I still like the idea of having the branch-name
somewhere in the version number or build number for debug builds.
Patrick Robertson
Rob McBroom
> A build number that doesn't increase with each build, but rather just...changes? No way. That's not good.
Wait, it has to be an incremental number now? Someone once said “the build number has exactly one purpose: To be used in the update system to communicate that there's a new version available”. :-) I’m just giving you a hard time, but in the end, it would still serve that one purpose.
> 1. It's confusing. To me. To the users. "I just updated to a new version, but now my build number than before. Was that a downgrade instead?”
They should be going by the version, not the build, right? And maybe it *is* a downgrade (in an emergency, like I said). We could also update the UI to make it clear this isn’t an incremental number. See the screenshot on Stack Overflow where they have something like “Version B66 (git sha 85756a1)”.
> 2. How do you make sure you don't get the same number twice?
I think it’s always unique, but for release (or pre-release) purposes, we’d only ever be getting it from one branch: master. In that case, it will definitely be different.
It’s just an idea. I’m not pushing it too hard, but I want to make sure it’s thoroughly torn apart before we dismiss it. It’s something we could automate and eliminate guess work, judgement calls, and memory lapses.
> Please just make it increase by one on each merge.
I’d be OK with just upping it by one on each *release* (or more if there was a pre-release that got modified prior to release). That eliminates the problem of the number increasing in parallel on two different branches.
> I still like the idea of having the branch-name somewhere in the version number or build number for debug builds.
Sounds good, if non-number values won’t break anything.
Henning Jungkurth
>
> Wait, it has to be an incremental number now? Someone once said “the build number has exactly one purpose: To be used in the update system to communicate that there's a new version available”. :-) I’m just giving you a hard time, but in the end, it would still serve that one purpose.
Sure, it would most likely work. IF we changed the update system. But
it wouldn't improve anything. So why change it at all. On the
contrary, it would make things worse, by making them more confusing.
> They should be going by the version, not the build, right?
Should they? Then why do we still display the build number?
> We could also update the UI to make it clear this isn’t an incremental number. See the screenshot on Stack Overflow where they have something like “Version B66 (git sha 85756a1)”.
Well, then why would we use some kind of strange number? Why not use
the git SHA? I like that. No need to manually or automatically
increase some number, because it's built into git. And we have the
direct connection to the history of the code. I do believe I have
mentioned that before.
> It’s just an idea. I’m not pushing it too hard, but I want to make sure it’s thoroughly torn apart before we dismiss it.
Same here :-)
>> Please just make it increase by one on each merge.
>
> I’d be OK with just upping it by one on each *release* (or more if there was a pre-release that got modified prior to release). That eliminates the problem of the number increasing in parallel on two different branches.
That's what we are doing right now, isn't it? But Patrick wanted
something more fine grained.
>> I still like the idea of having the branch-name somewhere in the version number or build number for debug builds.
>
> Sounds good, if non-number values won’t break anything.
The version is already not a number. I'm pretty sure ß isn't part of
any number-system. So it shouldn't be a problem.
I just tried it and it works fine.
Patrick Robertson
Rob McBroom
> But it wouldn't improve anything. So why change it at all.
Like I said in the last message, “It’s something we could automate and eliminate guess work, judgement calls, and memory lapses.” Sounds like quite an improvement to me. :-)
> Should they? Then why do we still display the build number?
We just talked about that. It’s the only thing the update system provides via HTTP. As for why it should be displayed in the UI of the installed application, it might help to ask users what it is from time to time (no matter what we settle on). Maybe it should only display in the About panel and not in the prefs?
> Well, then why would we use some kind of strange number? Why not use the git SHA? I like that.
What strange number? The git SHA is exactly what I was suggesting we use. What did you think I was talking about?
> The version is already not a number. I'm pretty sure ß isn't part of any number-system. So it shouldn't be a problem. I just tried it and it works fine.
Yes, that should work fine. You mentioned the build number, which is more what I was referring to. What do you think of something like this?
Debug build from CpMac: ß66:CpMac:Debug
Release build from CpMac: ß66:CpMac
Release build from master: ß66
That is, we always include the branch name unless it’s “master” (and I guess we should exclude “release”), so the final releases distributed to users don’t include it. (I avoided using `-` as a separator since it’s often part of the branch name.)
Henning Jungkurth
Oh. I did not know what 'git rev-parse --short HEAD' does. Now I know.
Sorry about that.
> Yes, that should work fine. You mentioned the build number, which is more what I was referring to. What do you think of something like this?
>
> Debug build from CpMac: ß66:CpMac:Debug
> Release build from CpMac: ß66:CpMac
> Release build from master: ß66
>
> That is, we always include the branch name unless it’s “master” (and I guess we should exclude “release”), so the final releases distributed to users don’t include it. (I avoided using `-` as a separator since it’s often part of the branch name.)
Sounds good. Originally I thought to just include it in the debug
versions, but your're right. If we exclude the master (and release)
branch, it should be fine on the release-builds as well.